Skip to main content

Advanced Security: Rate Limiting, Authorization & XSS

Rate Limiting (Advanced Strategies)

Problem with Per-IP Limiting​

  • Attackers can bypass using:

    • VPNs
    • Botnets
    • Rotating IPs

  • Shared networks (e.g., colleges) cause:

    • False positives

Per-Account Rate Limiting​

Concept​

  • Limit failed attempts per account

Example​

  • 5 failed logins → lock account for 24 hours

Benefit​

  • Protects targeted accounts
  • Stops brute force on a single user

Limitation​

  • Attackers can:

    • Try 1 password across many accounts
    • Avoid triggering per-account lock

Global Rate Limiting​

Concept​

  • Limit total login attempts system-wide

Example​

  • Max 100 attempts/minute globally

Benefit​

  • Stops distributed attacks:

    • Multiple IPs
    • Multiple accounts

Response Strategy​

  • Trigger alerts
  • Block suspicious IPs
  • Show CAPTCHA

Layered Rate Limiting Strategy​

  • Combine:

    • Per-IP
    • Per-account
    • Global

Goals​

  • Prevent:

    • Brute force attacks
    • Server overload (DoS)

Authorization Security

Authentication vs Authorization​

  • Authentication:

    • Who are you?

  • Authorization:

    • What can you do?

Where Vulnerabilities Arise​

  • Not in definitions
  • But in implementation gaps

Common Backend Flow

  • Routing Layer
  • Handler Layer
  • Service Layer
  • Repository Layer (DB access)

Typical Mistake​

  • Authorization checked only at:

    • Routing layer

False Assumption​

  • “User is authenticated → safe everywhere”

Broken Object Level Authorization (BOLA)

Definition​

  • User accesses resources they don’t own

Example Scenario​

  • API:

    GET /books?id=5

  • Backend query:

    SELECT * FROM books WHERE id = 5

Problem​

  • No ownership check:

    • User can access any book

Attack​

  • Iterate IDs:

    • /books?id=1,2,3,...

  • Extract sensitive data:

    • Invoices
    • Financial records

Fix​

  • Always include ownership check:
SELECT * FROM books 
WHERE id = 5 AND user_id = current_user

Key Insight​

  • Authorization must be enforced:

    • At the data layer (DB)

Information Leakage Issue

Bad Practice​

  • Return 403 Forbidden

Why It’s Dangerous​

  • Confirms:

    • Resource exists

Attack Result​

  • Attackers can:

    • Enumerate valid IDs

Better Approach​

  • Return 404 Not Found

Benefit​

  • Hides:

    • Whether resource exists

Broken Function Level Authorization (BFLA)

Definition​

  • Unauthorized access to functions/endpoints

Example​

  • Endpoint:

    /admin/invoices

Vulnerability​

  • Only hidden in frontend
  • No backend role check

Problem​

  • Any authenticated user can:

    • Call API directly

Fix​

  • Enforce role checks:
if user.role != 'admin':
    deny access

Key Principle​

  • ❌ Security through obscurity

  • ✅ Enforce server-side authorization

  • Should Add a middleware for this.

IDOR (Indirect Object Reference) X Broken Access COntrol Patterns (BACP)

Problem​

  • Predictable IDs:

    • 101, 102, 103...

Attack​

  • Guess IDs
  • Enumerate resources

Fix​

  • Use:

    • UUIDs (random IDs)

Tradeoff​

  • Slight performance cost
  • Much better security

Authorization Mental Model

Two Types of Attacks​

1. Horizontal Escalation​

  • Access other users’ data

  • Example:

    • BOLA / IDOR

2. Vertical Escalation​

  • Access higher privileges

  • Example:

    • BFLA (user → admin)

Authorization Best Practices

1. Centralize Authorization​

  • Avoid scattered checks

  • Maintain:

    • Single authorization layer

2. Default Deny​

  • If not explicitly allowed:
    • Deny access
  • If adding new resources, protected by default.

3. Test Authorization​

  • Test:

    • User A ≠ access User B
    • User ≠ admin actions
    • Unauthenticated access blocked

  • Fix:

    • Make Atomated Checks in CI/CD Pipeline.

4. Audit Logs​

  • Log:

    • Admin actions
    • Failed authorization attempts

  • Helps:

    • Detect attacks early

Cross-Site Scripting (XSS)

Definition​

  • Attacker executes JavaScript in:

    • Another user’s browser

JS normally has all the data and CAN READ COOKIES ALSO (as long they're not HTTP-only) for auth & session token.​

Why Dangerous​

  • Can:

    • Steal cookies/session
    • Make API calls as user
    • Redirect to phishing sites
    • Modify UI

Root Cause

  • Treating:

    • User input as code

Stored XSS

Scenario​

  • User submits comment with:

    • Malicious <script>

Flow​

  1. Stored in DB
  2. Sent to other users
  3. Rendered in browser
  4. Script executes

Example Context​

  • Markdown → HTML conversion
  • Injected into DOM

Dangerous API​

  • dangerouslySetInnerHTML (React)

    There are Reflected XSS,DOM Based XSS.​

    User defined content being treated as code rather than data.​

    Happens in User's browser.

Fix: Sanitization

Server Responsibility​

  • Remove:

    • <script> tags
    • Dangerous attributes

Rule​

  • Always sanitize anything given by user:

    • Before storing or rendering

Content Security Policy (CSP)

What It Is​

  • HTTP header controlling:

    • What browser can execute

Example Rules​

  • Only allow scripts from trusted domains
  • Block inline scripts

Role​

  • Acts as:

    • Last line of defense

Important​

  • CSP ≠ primary protection
  • Sanitization still required

CSRF (Brief Overview)

Concept​

  • Browser sends cookies automatically

Attack​

  • Malicious site triggers request:

    • Using user’s cookies

Why Less Relevant Today​

  • Modern protections:

    • SameSite cookies
    • CORS policies

Prevention​

  • Use:

    • SameSite = Strict/Lax - By Default (Lax)
    • Secure cookies

Misconfiguration Risks

1. Secrets in Code​

  • Storing API keys in Git

Risk​

  • Anyone with repo access:

    • Gets secrets

Fix​

  • Use:

    • Environment variables
    • Secret managers

Important​

  • If leaked:

    • Rotate immediately

2. Debug Mode in Production​

  • Logs include:

    • Stack traces
    • SQL queries
    • Sensitive data

Risk​

  • Info leakage via logs

Fix​

  • Use:
    • INFO level in production
  • Set LOG level of your staging, production and local environment.

3. Security Headers​

  • Examples:

    • CSP
    • X-Frame-Options

Benefit​

  • Prevent:

    • Clickjacking
    • Script injection

Implementation​

  • Use middleware:
    • Auto-configures headers

Core Security Philosophy

Everything is About Boundaries​

  • Vulnerabilities occur when:

    • Data crosses boundaries

Examples​

  • User input → SQL → Injection
  • User input → HTML → XSS
  • User → Other user’s data → BOLA

Questions to Ask Always

  • Where is data crossing boundaries?
  • What assumptions am I making?
  • What if those assumptions are wrong?

Defense in Depth (Layers)

1. Input Validation​

  • First line of defense

2. Parameterized Operations​

  • Prevent injection

3. Authorization at Access Point​

  • Check where data is accessed

4. Security Headers​

  • Limit damage

5. Monitoring & Logging​

  • Detect suspicious activity

Final Takeaway

  • Security is not:

    • A feature

  • It is:

    • A mindset

Golden Rule​

  • Always think:

    • “How can this be abused?”

Resources​

https://portswigger.net/web-security https://owasp.org/www-project-top-ten/ https://cheatsheetseries.owasp.org/index.html